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his is a response to Juanita Ewing’s “Should classes have owners?” article in 
the September 1991 issue of The Smalltalk Report. There are several themes 
in the article with which I’d like to take issue. 1 have been a Smalltalk pro¬ 
grammer for some years now, and for about the last nine months several of 
us at Knowledge Systems Corp. have been extensively using a commercially available de¬ 
velopment environment that pervasively supports the concept of class ownership. This is 
the ENVY/Developer team development tool running on Smalltalk/V PM and 
Smalltalk/V Windows. This is a powerful programming environment designed to facilitate 
cooperative software development among a team of programmers. The tool is flexible 
enough to cater to the needs of multiperson teams as well as the lone programmer. For the 
purposes of this article, I shall use the term ENVY to refer to ENVY/Developer. 

It is in the context of my experience of having developed Smalltalk code using a team 
tool like ENVY in an inherently multiperson environment that I shall address each of the 
issues Juanita has raised. 1 shall also attempt to provide technical as well as sociological 
answers to the questions she has raised. 1 use ENVY here to set a practical context for doc¬ 
umenting my experience with many of the class ownership issues discussed in the original 
article. Readers should not misconstrue this as a commercial plug for the product. 

TERMINOU K»Y PRELUDE 

Before delving into specific issues, let us define some key terms relevant to this discussion. 
ENVY supports the notions of class owners and class developers. A class is only one of many 
software components that have an ownership aspect associated with them. Ownership im¬ 
plies that someone is responsible for controlling a software component’s evolution. This 
control manifests itself in the fact that only an owner can release a class for public con¬ 
sumption. 

The granularity of a software component can he varied: a method, class, set of classes, 
set of sets of classes, etc. ENVY also supports an additional programming environment 
structure called an application. An application is a collection of defined and extended 
classes that together accomplish a well-defined purpose. In addition to providing a physi¬ 
cal organization of related classes, it also serves as a large-grain reusable component. Team 
members no longer just talk about reuse of a single class; they talk about reuse of function¬ 
ality. This is good because the responsibility for accomplishing a given piece of functional¬ 
ity may he distributed among a set of closely collaborating classes. 

Class developers are team members who may author one or more classes in the applica¬ 
tion. They may he distinct from the person who actually owns the class. 

WHO IS UES I QUALIFIED TO FIX THE BUli OR WRITE THE NEW 
METHOD? 

Juanita writes: "assume the owner of a class is rewarded for producing a reusable class. 
What if another developer finds a bug in that class or thinks of a useful extension? In a 

cun tinned on J*i£i? 4 . . 
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n last month’s editorial, we urged you to take our columnists to task if you did not agree 
with their opinions on particular topics. Well, you did just that! The approach to change 
management proposed by Juanita Ewing in her opening Getting Real column, “Should 
classes have owners?,” has spurred several well-known members of the Smalltalk commu¬ 
nity to put forward their ideas. In this month’s lead article, S. Sridhar from Knowledge 
Systems argues that, based on his experience, class ownership is indeed a primary compo¬ 
nent of any strategy for managing change in large Smalltalk applications. Next month, 
Jeff McKenna will put forward his view that change management is best organized 
around what he refers to as the two distinct phases of software development using 
Smalltalk—functional expansion and consolidation, Change management seems to be a 
topical subject right now, and we look forward to hearing your views. 

Two of our regular columnists appear in this issue. Rebecca Wirfs-Brock continues her 
Object-Oriented Design column by discussing the importance of understanding object 
roles and responsibilities. In this month’s Getting Real column, Juanita Ewing begins a 
two-part article on the appropriate use of class variables and class instance variables. 

Also in this issue, Glen Reid, the architect of the Smalltalk/370 project, continues his 
description of their project. In this issue, he discusses in detail many of the implementa¬ 
tion issues that are specific to implementation on a mainframe, including a scheme to in¬ 
troduce explicit variable typing in Smalltalk. 

Rounding out this issue, Jon Hylands takes a look at the first of a new line of third party 
Smalltalk products, Profile/V, a code profiling tool that can be used to monitor the per¬ 
formance of Smalltalk applications. Finally, Dan Lesage reviews Object-Oriented Modeling 
and Design by James Rumbaugh et al. 

The Smalltalk Report is still finding its feet. Let us know what you like, what you don’t 
like, and what you would like to see. We look forward to hearing from you and hope you 
enjoy this issue. 
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■ Should classes have owners? 


continual from page 1... 

system with class ownership, the owner writes the code to fix 
the bug or writes a new method. He is the one motivated to 
make the class more reusable." 

First, the case where a developer finds a bug. Suppose I 
own a reusable class called Drawing. If another developer, say 
Harry, finds a bug in Drawing, he creates a scratch edition of 
the application containing the class Drawing, creates a new 
edition of Drawing, fixes the bug, versions the change, and in¬ 
forms the owner via email or otherwise of the fix. I, as the 
owner, can examine the fix at my leisure, assess the impact on 
the clients of the method, and, if all is well, incorporate the 
fix into a future version of Drawing and then release it for pub¬ 
lic consumption. Alternatively, I could simply release the ver¬ 
sion of Drawing that Harry created. In the meantime, Harry 
can continue to use the scratch edition of Drawing and do 
anything he pleases to any of the existing methods of Drawing 
without impacting any other team member. When I have re¬ 
leased a new version of Drawing, he can load it into his envi¬ 
ronment, replacing the scratch edition. 

Thus, it is that Harry and I have resolved the bug by en¬ 
gaging in a harmonious electronic “conversation” without dis¬ 
rupting any other team member. He found the bug, submitted 
a fix, and continued to do his work with his fix without await¬ 
ing my approval. 1, as the owner of the method, evaluate the 
quality of the fix, assess the impact of the fix, and then fold it 
into the next version of the class and release it for our team’s 
use. The owner is the best person to assess the overall impact 
since he is the one who most intimately knows the raison 
d'etre for the method in the first place. He is probably the 
most aware about the way in which existing and potential 
clients use the method. ENVY automatically records the au¬ 
thor and time stamp of the fixed method. 

Alternatively, Harry can create a new working copy or edi¬ 
tion of Drawing along a different stream of development or 
versioning branch. When he is done fixing the bug, he ver¬ 
sions the class with a mnemonic version label. (The 
mnemonic label is not required; it is just a convention we 
have adopted to meaningfully identify the different versions of 
a class.) The owner then merges his contributions with the 
officially released version of Drawing. The point of all this is 
that: 

• With good communications (which is required anyway for 
healthy project sociology), class ownership does not ham¬ 
per the evolution of a class into the reusable club. This is 
primarily because changes to the class can be made asyn¬ 
chronously. 

• The owner reviews the fix in a different context from that 
of the other developers. It is his responsibility to guarantee 
the proper functioning of all the advertised interfaces of his 
class and to the extent possible be familiar with all the us¬ 
age contexts of his class. 


ADDING CLASS EXTENSIONS 

The case where Harry finds a useful extension to Drawing is 
easily dealt with in ENVY. As a matter of fact, this situation 
occurs constantly in our work with system classes like String, 
Stream, etc. ENVY provides a programming environment ab¬ 
straction called class extension that allows a developer to add 
brand new methods to an existing class. These method exten¬ 
sions are localized to the application in which the extension is 
defined. Thus, Harry can add a new method to Drawing by cre¬ 
ating an extension of Drawing in his application. Even though 
I am the owner of Drawing, Harry does not require my permis¬ 
sion to add the useful extension he needs. Furthermore, this 
extension does not compromise the integrity of the original 
class. A malicious Harry could, of course, destroy the class’ in¬ 
tegrity by writing a method extension that corrupts the inter¬ 
nal state of the class in a way that is incompatible with the rest 
of the class' behavior. The users of Harry’s code are the losers. 
Team sociology being what it is, Harry would be quickly ex¬ 
posed by the users and be pressured to undo his mischief. 

It should be noted that the person who creates a class ex¬ 
tension in a different application actually owns the extension. 
Class extensions are a powerful mechanism for specifying and 
managing application-specific behaviors for existing classes 
and for dealing with orthogonal protocols for classes where 
several developers are authoring different parts of the same 
class. By splitting these orthogonal protocols along their func¬ 
tional views using applications, multiple developers on a sin¬ 
gle class can be managed realistically and effectively. 

REWARDING REUSE 

Juanita correctly notes that if a reusable class is provided by a 
team of developers then the entire team should be rewarded. 

It is our experience that a reusable class usually has a primary 
author (or owner in ENVY parlance) and it can have multiple 
developers different from the author. These secondary authors 
can be reviewers, bug finders and fixers, and maybe even coau¬ 
thors. Again taking the Drawing example, I may find that 
Harry has made a dozen extensions to Drawing in his applica¬ 
tion. Upon close examination, I determine that these exten¬ 
sions are useful and general enough to warrant inclusion in my 
Drawing class. In ENVY, as the class owner, I simply add 
Harry as a developer of the class, have him promote the dozen 
deserving methods to my reusable rendition of Drawing. All 
the newly promoted methods carry Harry’s imprimatur. Thus, 
Harry and I are established as coauthors of Drawing. Since the 
programming environment explicitly identifies the people 
who are working on an application (a large-grain reusable 
component), it is easy to identify who to reward. A picky 
manager can even measure the relative contributions to the 
reuse genre and can thereby dispense rewards proportionately! 

There is an interesting sociological aspect to this reward is¬ 
sue that runs somewhat orthogonal to class ownership. If 
Harry makes a change to my class that I don’t like—as in 
Juanita’s world—who wins? As my colleague Lynn Fogwell 
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observes, being clear about who owns what, or more precisely 
who is responsible for what, actually goes a long way in resolv¬ 
ing conflicts before they get started. 

FLEXIBLE PROGRAMMING ENVIRONMENT 

I agree with Juanita that “flexibility in programming environ¬ 
ments is critical.” I disagree with her statement, “Systems with 
class ownership are not flexible." A good programming envi¬ 
ronment should be able to maintain flexibility without com¬ 
promising the integrity and reliability of the classes. The pro¬ 
gramming environment should be flexible enough to cater to 
widely different organizational cultures and software environ¬ 
ments. It should be appealing to the “rape and paste" rapid 
prototyper as well as the person who is engaged in production 
software engineering. In addition, it should be forgiving of the 
user's mistakes. 

In a production software environment, it is often necessary 
to maintain comprehensive change control over the various 
software elements; otherwise, system integration becomes a 
nightmare. In certain organizations, it may be mandated that 
third party reusable classes not be tampered with, for fear of 
compromising the integrity and reliability of client code that 
is dependent on them. Indeed, the reusable class vendor (an 
internal organization or an outside source) may have shipped 
a class library without any source. This is eminently possible 
when classes are packaged as dynamic link libraries. Under 
these circumstances, even though you cannot modify an exist¬ 
ing method, in ENVY you can add extensions to these other¬ 
wise read-only classes in your own application. 

Juanita notes the difficulty in managing the ramifications 
induced (vis-i-vis class ownership) by introducing changes in a 
class hierarchy- She concludes, using an interesting syllogistic 
argument, that therefore the same developer must own all the 
classes in the hierarchy. This need not be the case at all. In 
fact, it is impractical to expect that the superclass and subclass 
owners be the same. Often times the superclass owner may be a 
third party vendor or a different organization geographically re¬ 
mote from the subclass developer. In a programming environ¬ 
ment such as ENVY with comprehensive version control and 
configuration management facilities, a complete system con¬ 
sists of a collection of compatible applications. By compatibil¬ 
ity I mean, for instance, that the well-being of a subclass client 
depends upon a properly functioning superclass. Now if the su¬ 
perclass owner makes a change in his class, it may indeed com¬ 
promise the integrity of the subclass. It is therefore incumbent 
upon the subclass owner to adapt his class to the newly 
changed superclass before a new configuration of the integrated 
system is released. This is no different from the everyday situa¬ 
tion where we developers have to port our classes to new ver¬ 
sions of the Smalltalk products from vendors. 

I agree with Juanita's concluding premise that classes de¬ 
veloped by multiple programmers are understood by multiple 
programmers. I disagree with her observation that class owner¬ 
ship is an obstacle to accomplishing that. Classes in Smalltalk 


often reflect the style and personality of the author. Having 
too many developers on a single reusable class may introduce 
conflicting styles, idioms, and figures of speech that together 
strike a discordant note to the hapless client- As a flexible 
programming environment, ENVY recognizes the need for 
new extensions to existing classes and therefore permits the 
distribution of protocol among several applications possibly 
authored by different programmers for ever-so-specialized rea¬ 
sons. The primary author serves as a focal point for the evolu¬ 
tion of the reusable class. A class, in the course of its lifetime, 
may see its author pass on to a different project or even leave 
the company. Or, the author may want someone else to as¬ 
sume the class' maintenance. Flexible programming environ¬ 
ments provide mechanisms for effecting a smooth change of 
guard to establish a new class owner. 

CONCLUSION 

The features and philosophy of class ownership (and indeed 
that of software component ownership) foster a disciplined 
software environment without compromising the classical 
productivity gains of Smalltalk. Class ownership itself is inad¬ 
equate. The ownership mantle has to be pervasively applied 
across all the different units of software that together comprise 
a complete system. This requires a programming environment 
that uniformly applies the ownership philosophy across the 
various development tools. It should be flexible enough to ac¬ 
commodate different organizational work cultures vis-a-vis 
team programming. 

Class ownership provides a framework for properly separat¬ 
ing the activities of component building from application 
building. Component builders are those people whose major 
goal is to build reusable components and who should have a 
reward structure to match. Application builders are trying to 
get an end user system out the door, and programming for 
reuse may not be a critical factor for them. Even if developers 
have to play both roles, it is important that they understand 
and record the role that they are playing at anytime. Owner¬ 
ship and responsibility for software is a key factor in long-term 
software quality and reusability. ■ 


S. Sridhar is a senior member of the technical staff at Knowledge Sys¬ 
tems Carp, in Cary, NC where he is actively applying Smalltalk to a 
variety of software engineering problems. He has also developed sub- 
stantiai applications designed to meet specific customer requirements. 
He came to KSC from Mentor Graphics Carp, where he was the pro¬ 
ject lead for Mentor’s next generation design management environ¬ 
ment developed in C++. Prior to that he worked at Tektronix for four 
years on Common Lisp and Smalltalk/80 product development. While 
at Tektronix, he developed numerous tools and components running 
in the Smalltalk/80 environment. He was an early developer of a 
framework for delivering stand-alone Smalltalk applications. 
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BJECT-ORIENTED DESIGN 


Rebecca Wirfs-Brock 


Determining object 
responsibilities 

D onald Norman, 1 in The Design of Everyday Things, makes 
the following statement: 

Consider the objects—books, radios, kitchen appliances, 
office machines, and light switches—that make up our ev¬ 
eryday lives. Well-designed objects are easy to interpret 
and understand. They contain visible clues to their opera¬ 
tion. Poorly designed objects can be difficult and frustrat¬ 
ing to use. They provide no clues—or sometimes false 
clues. They trap the user and thwart the normal process of 
interpretation and understanding. Alas, poor design pre¬ 
dominates. The result is a world filled with frustration, 
with objects that cannot be understood, with devices that 
lead to error. 

I never thought I'd say this, but software objects are like 
real-world objects! Both kinds of objects are hard to use if they 
are poorly designed- Ensuring that software objects are easy to 
use involves paying attention to a number of sound design 
principles. No one ever said that good object-oriented design is 
easy. In this month's column. I'll discuss the importance of un¬ 
derstanding and modeling object roles. Once there is a clear 
sense of an object’s intended purpose, it is much easier to detail 
the necessary behavior in an understandable fashion. 

Identifying the central classes in an application is just the 
first step. Combing through a specification of the problem may 
provide an initial list of candidate classes, but what next? 

First, let me state that no designer I know has ever found all 
the key objects by reading and understanding a specification 
of the problem. A specification is just a launch pad for design 
activity. Depending on the weight of that specification, there 
will be different strategies needed to find those key classes. If 
there is a mound of paper to wade through, the initial task will 
be one of filtering out a lot of detail and focusing on identify¬ 
ing the highest level concepts. On the other hand, if the 
specification is on the slim side, the task will be to develop a 
skinny statement of intent into a model of key concepts that 
will drive jhe design. 

There is a deceptively simple question that needs to be an¬ 
swered for each identified class. Can that class' purpose within 
the application be clearly stated? I've found it useful to force 
myself to write a concise, precise statement of purpose for 
each potential class. This purpose statement need not be long 


roles and 


or wordy; a sentence or two will often suffice. However, if it is 
difficult to construct a succinct statement, more work is 
needed. There are several plausible explanations (other than 
that the class doesn’t belong in the design) for being unable to 
write a clear purpose statement for a class. 

SUBDIVIDING LARGE CONCEPTS 
Fot one thing, the class may represent too large a concept. 
One indicator of this is that the class seems to embody an en¬ 
tire program or a major portion of the overall system behavior. 
This large concept needs to be decomposed into more under¬ 
standable pieces- What are the constituent responsibilities of 
this mega-object? To answer this question, we must resolve a 
rather complex concept into simpler, more basic ones. These 
simpler concepts will be easier to understand, and their pur¬ 
pose and role will be easier to elaborate. Simpler concepts will 
be represented by classes in the final design, while the larger 
concept may not. 


§§ 


... software objects are like 
real-world objects 




It is conceivable that the large, vague concept still has a 
role to play and will be represented by a class in the final de¬ 
sign. For example, the object might be responsible for coordi¬ 
nating the actions of other objects (each with a concisely 
stated purpose) that collaborate to fulfill the larger purpose. 
One design for an automated teller machine might have an 
automated teller session object whose purpose is to conduct a 
customer session. This customer session would consist of a se¬ 
ries of user transactions with the bank (and a whole chain of 
responses to user requests) that are coordinated by the auto¬ 
mated teller object. 

Subdividing the responsibilities of a large, complex class 
into a number of simpler classes requires deeper understanding 
of the system. Each newly created class needs a clearly stated 
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role. There already may be identified classes that can fulfill 
part of the responsibilities of the rather large concept. Most 
likely, this isn't the case. A hypothesis must then be formu¬ 
lated on how to partition the vague concept into several dis¬ 
tinct roles. Each role will be assigned to a new class. A key de¬ 
signer of a large, successful application told me that his design 
team subdivided responsibilities according to when, what, and 
how. These subresponsibilities were then assigned to separate 
classes that were either responsible for knowing when, know¬ 
ing what, or knowing how to perform an operation. Sounds 
simple enough. The design team found they spent time debat¬ 
ing whether a particular responsibility was actually a when, a 
what, or a how. One object's what is another object’s how. It 
all depends on a particular point of view. At least the team 
had a strategy for elaborating class roles. But they still had to 
debate the details in context of their emerging model. 

COMPLETING A MODEL OF OBJECT INTERACTIONS 
There are other situations where it is difficult to state a class' 
purpose. One common situation is that a class doesn't seem to 
be connected to any others. It’s hard to explain why this dis¬ 
joint class should exist, yet the designer remains convinced 
that it's important. Chances are, the class is important- The 
problem is that the model is incomplete- This problem typi¬ 
cally arises when classes are sifted through one at a time, 
rather than building an understanding of the collaborative be¬ 
havior between objects in the design. 

To understand any single object's role, it must be looked at 
in the context of others with which it interacts. Constructing 
an object-oriented design is not a linear, top-down process, al¬ 
though it is often to present the design that way. Understand¬ 
ing an object’s purpose forces the designer to understand the 
roles of other objects. To understand the role of a seemingly 
isolated object, both an understanding of its static, structural 
relationships with other objects and interactions with other 
objects is needed. 

To determine the static relationships an object has with 
others, examine how an object is connected to others. Is there 
a whole-part relationship between it and another object? 

Does this object represent an aggregation of other objects? If 
so, it is usually pretty simple to fit this object into the design. 

It is much harder when an object participates in a number 
of relationships- In this case, it is useful to build an under¬ 
standing of the dynamic behavior of the object. Performing 
design walk-throughs by tracing a chain of object collabora¬ 
tions in response to a stimulus is a good way to understand ob¬ 
ject interactions. Ivar Jacobson, 2 pioneer of the Objectory 
method, introduced the notion of usage cases. Usage cases can 
be recorded and then used to test the model under both nor¬ 
mal and abnormal conditions. A key component of Steve 
Weiss and Meilir Page-Jone’s 3 object-oriented software syn¬ 
thesis method is modeling the response to events and under¬ 
standing their impacts on a design. The idea behind both 
techniques is to translate requirements into events and to as- 
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sociate events with objects that are responsible for handling 
them. 

The more situations that are modeled, the better. As sim¬ 
ple as this sounds, it takes some skill to effectively elaborate 
object interactions. The goals is to first develop a "big picture” 
before diving into detail- The way to do this is to trace object 
collaborations between objects that are at either the same or 
next conceptual level in the design. First, develop an overall, 
high-level view of key object interactions. Then elaborate and 
subdivide roles and object responsibilities. This breadth-first 
approach avoids modeling classes at widely differing concep¬ 
tual levels, which indeed is difficult. 

This breadth-first approach represents an ideal. In practice, 
some areas of the design will be better understood and naturally 
elaborated before others. An uneven design model can make it 
difficult to trace object collaborations. It will be relatively easy 
to trace the collaborative behavior throughout the well-under¬ 
stood parts of the design. When collaborations are necessary 
with objects in an undeveloped area, suddenly what had seemed 
straightforward becomes very unclear. This isn’t a sign of fail¬ 
ure; it just indicates that the unclear part needs elaboration. 

OBJECTS THAT DON’T FIT THE MODEL 
Perhaps one of the toughest problems to deal with is when an 
object doesn't fit with the designer’s notion of what consti¬ 
tutes a “good” object. It is very difficult to explain the purpose 
of such misfits. Criticisms commonly leveled against such 
troublesome objects are: 
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• This is an organizing object. It is too simple. It merely 
consists of data. It has no behavior. Aren’t objects sup¬ 
posed to have both? 

• This object's only purpose seems to be to route messages 
between two other objects. Why should I have intermedi¬ 
ary between these objects? Can't they just directly commu¬ 
nicate with each other instead? 

• This object is too action oriented. Aren’t objects supposed 
to encapsulate both operations and data? This object seems 
like a pure ‘‘process.” We’re doing an object-oriented de¬ 
sign, not a process decomposition. 


§§ 

Constructing an object-oriented 
design is not a linear, top-down process, 
although it is often useful to present 
the design that way. 


There are no pat answers to these criticisms. In each case, 
the object doesn’t match the designer’s expectations. The 
model, the designer’s expectations, or both need readjust¬ 
ment. In the first case, it is worth noting that objects are not 
uniform packages of operations and data. It is natural that the 
proportion of each will vary according to the object’s role in 
the design. It is perfectly reasonable for relatively simple ob¬ 
jects to coexist alongside more complex ones. However, the 
object must stand on its own merit to be included. Indeed, 
there may be preferable alternatives to creating a "data 
mostly” object. 

When creating an object model, the designer may need to 
invent mechanisms that weren't spelled out in the 
specification- Mechanisms may be added for the express pur¬ 
pose of reorganizing the flow of information and communica¬ 
tion between objects. These mechanisms may help reduce ob¬ 


ject coupling or provide an abstract connection between ob¬ 
jects. The consequences of inserting such mechanisms needs 
careful consideration. Buc, objects whose purpose is to orga¬ 
nize or manage communication between objects can be rea¬ 
sonable design additions. 

In the third case, the purpose of an object may be to trans¬ 
form information from one form to another. Such process-ori¬ 
ented objects can naturally occur in a design and are not al¬ 
ways a sign that the designer hasn’t shifted from the 
procedural to the object-oriented paradigm. Each process-ori¬ 
ented object should apply a fair amount of intelligence to pro¬ 
duce results. Better yet, a process-oriented object can often 
provide a completely different view on the transformed infor¬ 
mation. The objects being processed and the clients request¬ 
ing the transformed information may be only dimly aware of 
each other. In this case, the process-oriented object is proba¬ 
bly a reasonable design concept. One example of a process- 
oriented object is a compiler. The role of a compiler is to 
transform text into an executable program structure. It takes a 
lot of intelligence to perform this operation. Defining a com¬ 
piler object is a reasonable design choice. 

It may be that a class doesn’t belong in the final design. 
Websters Dictionary defines role as "a character assigned or as¬ 
sumed. A part played by an actor or singer.” The task of the 
designer is to assign each object an appropriate role. Each role 
is constrained to fit within the existing object model, but a lot 
of designer discretion is still involved- It's a challenge to de¬ 
sign well-understood, easy-to-use objects. But the positive im¬ 
pacts that well-designed objects have on application mainte¬ 
nance and understandability are well worth the extra effort. ■ 
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ETTING REAL 


Juanita Ewing 


How to use class variables and class 
instance variables, part 1 


I n last month's column, I discussed some strategies for initial¬ 
izing classes and how initialization related to class variables 
and class instance variables. In this column, I will talk about 
coding conventions for class variables and when to use class 
variables vs. class instance variables. 

Classes that use class variables can be made more reusable 
with a few coding conventions. These coding conventions 
make it easier to create subclasses. Sometimes developers use 
class variables inappropriately. Inappropriate use of class vari¬ 
ables results in classes that are difficult to subclass. Often, the 
better implementation choice for a particular problem is a 
class instance variable instead of a class variable. 

WHAT ARE CLASS VARIABLES? 

Classes can have: 

• class variables 
• class instances variables 

Class variables are referenced from instance and class methods 
by referring to the name of the class variable. Any method, ei¬ 
ther a class method or an instance method can reference a 
class variable- Figure 1 contains a diagram of a class, Ustlnter- 
face, that defines a class variables. 

The methods in Iistlnterface would look like this: 

Iistlnterface class 
initialize 

"Create a menu.” 

UstMenu := Menu labels: #('add"remove') 

Iistlnterface 

hasMenu 

"Return true if a menu is defined." 

''UstMenu notNil 

perfonnMenuActivlty 

"Perform the mouse-based activity for my view." 
self hasMenu 

ifTrue: [ A IistMenu startup]. 

Both instance and class methods can directly reference 
class variables by name. The class method initialize is used to 
bind values to the class variables. The instance methods has¬ 


Menu and performMenuActivity reference the class variable List- 
Menu. All instances of Iistlnterface and the class Iistlnterface 
share the same class variables. 

HOW ARE CLASS VARIABLES INHERITED? 

Class variables and the values they are bound to are inherited. 
The class variable referenced by a subclass is the same as the 
one referenced by the superclass- This means that a class vari¬ 
able is shared by a class, all its subclasses, and all the instances 
of the class and its subclasses. 


€6 

It is possible for subclass methods to 
modify inherited class variables, but 
generally it is undesirable to do so. 


Our example has a subclass of Iistlnterface called Calculat- 
edlistlnterface. Subclass methods referring to the UstMenu 
class variable reference exactly the same object as the super¬ 
class method. The subclass CalculatedListlnterface has behavior 
that is different from its superclass, as defined by the method 
conditionalMenuActivity: 



Figure 1. Class variables are refernced by subclasses and all instances. 
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CalculatedListlnterface 

condltUraalMenuActivity 

"Perform the mouse-based activity for my view if the list is not 
empty. If there is no menu, flash the list pane." 

self hasMenu 

ifFalse: ["self flash], 
list isEmpty 

ifFalse: ["ListMenu startup]. 

Subclass methods can directly reference class variables that 
are defined by the superclass. In our example, the Calculated¬ 
Listlnterface method references the class variable ListMenu that 
is defined by Iistlnterface. This is different from the inheri¬ 
tance of instance variables. The method conditionalMenuActiv- 
ity references the instance variable list that is defined by the 
class Iistlnterface But, each instance of CalculatedListlnterface 
and Listlnterface has its own copy of list and does not share its 
instance variables. 


ers want to create a new class variable and use it in place of 
the inherited class variable. 

Using our example, we will create a new menu in the sub¬ 
class CalculatedListlnterface. The menu is implemented with a 
class variable so it is not possible to change the menu for the 
subclass without also changing it for the superclass. This is be¬ 
cause both classes reference the same variable. 

The only way to create a new menu for the subclass and re¬ 
tain the original menu for the superclass is to create a new 
class variable. In our example, we call the new class variable 
CalculatedlistMenu. In addition to a new class variable, all 
methods that reference the original menu must be overridden 
in the subclass: 

CalculatedListlnterface class 

initialize 

"Create a calculated menu." 


HOW DO SUBCLASSES MODIFY CLASS VARIABLES? 
It is possible for subclass methods to modify inherited class 
variables, but generally it is undesirable to do so. If a subclass 
were to modify a class variable, it would change the only ex¬ 
isting value of the class variable. Each subclass does not have 
its own copy. It references a shared copy. Generally, develop- 



Smalltalk/V users: the tool 
for maximum productivity 


* 


Put related classes and methods into a single task- 
oriented object called application. 

Browse what the application sees, yet easily move code 
between it and external environment 
Automatically document code via modifiable templates 
Keep a history of previous versions; restore them with 
a few keystrokes. 

View class hierarchy as graph or list. 

Print applications, classes, and methods in a formatted 
report, paginated and commented. 

File code into applications and merge them together. 
Applications are unaffected by compress log change 
and many other features.. 


Imagi 



Class 
Application] ^ 

.Yam L 

History — 


] Deleted classes j 

Deleted methods ~\ 
Code recoveryl 


Utilities.. -[ Application printing | and more.. 


CodelMAGER™ V286, VMac $129.95 
& VWindow $249.95 

Stnpfmg & handling: SIS mill, 120 UPS, pa copy 

_ Diskette: 0318 □ 5m _ 

SixGraph™ Computing Ltd. 
formerly ZUNIQ DATA Corp. 

2033 Cote de Liesse, suite 201 
, > h, Montreal, Que. Canada H4N 2M5 

4|XV«££l3> Tel: (514) 332-1331, Fax: (514) 956-1032 

Code IMAGER la iicg. trademark of Six Giron C anjjuLuj g Ltd. 
SmaUtaUc/V b i reg. mdsmadc of Dighslk, Idc. 


CalculatedMenu := Menu labels: #('add' 'remove' 'print') 

CalculatedListlnterface 

hasMenn 

"Return true if a menu is defined." 

"CalculatedMenu notNil 

performMenuActivity 

"Perform the mouse-based activity for my view." 

self hasMenu 

ifTrne: ["CalculatedMenu startup]. 

Because direct references to the class variable ListMenu are 
sprinkled throughout the class Listlnterface, the subclass must 
override many methods. In this simple example, we had to 
override three methods that reference ListMenu to reference a 
different menu. In a complicated real-world application, many 
other methods may need to be overridden to reference a dif¬ 
ferent class variable in a subclass. Because significant portions 
of the class needed to be overridden, the class is not very 
reusable. 



Figure 2. Ceding conventions increase the reusability of classes 
implemented with class variables. 
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A better version of Listlnterface has the minimum number 
of references to a class variable—one for setting and one for 
retrieving the value of a class variable: 

Listlnterface class 

initialize 

‘Create a menu. Create constants." 

ListMenu := Menu labels: #('add"remove’) 

menu 

‘Return the list menu." 

"ListMenu 

Listlnterface 

hasMenu 

"Return true if a menu is defined." 

"self class menu notNil 

performMenuActivity 

"Perform the mouse-based activity for my view." 
self hasMenu 

ifTrue: ["self class menu startup]. 


fi 

Because of the nature of the data 
stored in class variables, it is best for 
class methods to store and retrieve 
the class variables. 


This coding convention reduces the number of direct refer¬ 
ences to a class variable, as illustrated in Figure 2. It is easier 
to create subclasses because only the methods that set and re¬ 
trieve the class variable need to be overridden. Now the code 
for Calculatedlistlnterface looks like this: 

CalculatedUsQnterface class 

initialize 

'Create a a computed list menu." 

CalculatedMenu := Menu labels: #('add' 'remove' 'print') 

menu 

"Return the list menu." 

"CalculatedUstMenu 

This coding convention effectively restricts the references 
to a class variable. Because of the nature of the data stored in 
class variables, it is best for class methods to store and retrieve 
the class variables. In effect, we have eliminated the sharing 
between classes and instances. 
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By eliminating this sharing, we have made Listlnterface 
more reusable; however, Listlnterface still has another prob¬ 
lem. Another class variable had to be created by the subclass 
to provide a different menu. Now Calculatedlistlnterface has 
two class variables, one of which (ListMenu) is not used. 

The root of the remaining problem is that class variables 
are shared by a class and its subclasses. In our example (and in 
many other situations), this sharing is inappropriate. Instead, 
a subclass needs to be able to override inherited data. Class 
variables share the data between subclasses and superclasses, 
so it's not possible for a subclass to override the data. Next 
month, we will explore another mechanism, class instance 
variables, that will solve our problem. E9 
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Smalltalk 


COMES TO THE 


MAINFRAME, 


PART 2 


Glenn ]. Reid 


O n part 1 of this article, we discussed our implemen¬ 
tation of Smalltalk in an IBM mainframe environ¬ 
ment that we have called Smalltalk/370. Mention 
was made that we are investigating the introduc¬ 
tion of typing into Smalltalk, currently a popular area of inter¬ 
est in the OO community. Here, in part 2, we will discuss some 
specifics of our investigation (not yet complete) and, hopefully, 
shed some light on the difficulties involved in typing a lan¬ 
guage like Smalltalk. 

Before we launch into a discussion of solutions, perhaps it 
would be appropriate to determine what we are investigating 
and why. In part 1, we stated that the performance overhead 
of dynamic (or late) binding would probably be unacceptable 
in Smalltalk/370, particularly since degradation of the system 
affects all users in a time-sharing environment. The fastest 
untyped version of Smalltalk today is the ParcPlace 
Smalltalk-80 implementation, which runs at approximately 
10% the speed of optimized C. This does not imply that the 
basic mechanism of dynamic binding in Smalltalk must be 
thrown out. As with many performance problems, it is very 
possible that concentrating on a few areas of concern will 
lead to a satisfactory system. Since dynamic binding is the 
problem, we must substitute statically bound procedure calls 
or, better yet, in-lined procedures in the areas where they 
provide the most benefit. 

When we first considered the dynamic binding problem, we 
felt that we would probably be able to implement a static typ¬ 
ing mechanism that would allow programmers to explicitly de¬ 
clare variable types within their programs and enable our com¬ 
piler to make use of these for optimization purposes. In our first 
attempt, we limited the scope of our ability to explicitly type 
Smalltalk. Since performance was our main goal, rather than a 
comprehensive typing system, we considered this approach ac¬ 


ceptable. We have included a few of the details of this ap¬ 
proach later in this article. 

As our static typing mechanism gained in substance, a num¬ 
ber of things became apparent. Explicit type declarations in¬ 
crease system complexity from the users perspective. A new di¬ 
mension is required in programmer thinking. Not only must 
performance requirements be observed in producing algorithms 
that operate efficiently, but all variations of types that the algo¬ 
rithm could operate upon must be considered as well as the rel¬ 
ative volume of message sends to each type. It is possible that 
subsequent changes to the system may make previous tuning 
invalid. Furthermore, type declarations may restrict the appli¬ 
cation of a method. For example, a method argument may be 
typed, causing method failure, similar to primitive failure, 
when an argument with an incorrect type is received. This 
makes the programming environment less flexible, or more 
complex from the programmers point of view. Intuitively, it 
appears that these complexities will increase if we expand our 
typing strategy. 

As part of our investigation, we are reviewing published lit¬ 
erature in the area of typing and optimizations to pure object- 
oriented languages. So far, we have come across three different 
approaches. 

Probably the furthest advanced example of comprehensive 
explicit typing within Smalltalk is the Typed Smalltalk (TS) 
project. 1 In this project, a syntax extension to Smalltalk allows 
the programmer to explicitly declare types for variables, 
method results, etc., that the compiler can use to statically 
bind or in-line procedures. Published performance results indi¬ 
cate that some small benchmarks have achieved speeds 
at least twice that of Smalltalk-80. Since this data is not re¬ 
cent, and we understand that work is still continuing on Typed 
Smalltalk, we expect that these results have been improved 
still further. This approach is closest to our initial experiments 
with explicit typing. Since this project is much further ad¬ 
vanced, we will probably look to it to evaluate some of our 
concerns mentioned above. 

Recent benchmark results in the SELF programming envi¬ 
ronment have demonstrated a Smalltalk-like language running 
at approximately 57% of the speed of optimized C. 2 These re¬ 
sults were achieved without the introduction of explicit typing 
within the language. In this approach, the compiler uses “path 
splitting” to generate both high- and low-performance paths 
through a method. Path splitting is used when a frequently used 
message selector whose receiver usually belongs to a particular 
class is detected within the source program. For example, path 
splitting would occur for the high-frequency message at:, which 
is most often received by an instance of Array, This approach 
uses the advanced techniques of dynamic compilation, cus¬ 
tomization, deferred compilation, and path splitting manage¬ 
ment algorithms to produce the results mentioned above. 

Finally, we have noted that some are working in the area of 
type inference without explicit typing. 3 Here, a type inferenc- 
ing algorithm constructs a graph of type constraints from a pro- 
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gram, The program is typeable if these constraints are solvable. 
Static binding information is derived from the solution. This 
project is currently implementing the inferencing algorithm, 
with an optimizing compiler as a future undertaking, and so 
has no performance results to report. In our initial exploration 
of explicit typing within Smalltalk, we have confined ourselves 
at this time to investigating typing of named variables, exclud¬ 
ing such things as intermediate results generated during expres¬ 
sion evaluation. Potential candidates for typing are: 

• dictionary variables (i.e., class, pool, and global variables) 

• instance variables 

• arguments 

• named temporaries 

• receivers 

In all cases, the affected variable would be constrained to 
belong to a particular class or one of its subclasses (i.e., the 
variable has been “typed”). Thus, we are using a simpler ver¬ 
sion of typing than that used in Typed Smalltalk. For this dis¬ 
cussion, type and class may be considered synonymous. Here 
are some of the issues involved. 

For programmer convenience, we would prefer a common 
type declaration syntax that could be used for all the above- 
mentioned cases. A possible candidate syntax is shown below: 

Current Smalltalk: vaiiableName 

Typed Smalltalk: (variableName:Class ) 

This new syntax would be used wherever variables are “de¬ 
clared” in Smalltalk, that is, in class definitions, message pat¬ 
terns, and declarations of temporaries. 

Typed variables must be initialized according to type. Un¬ 
typed variables are initialized at creation with the value nil. This 
is unacceptable for typed variables. If variable x is declared as: 

(xArray) 

we must ensure that x always contains an Array object; other¬ 
wise, invocation of the statically bound expression: 

xat: 1 

would have disastrous results. This requires a modification to 
the new and new: methods of class Behavior. Variables typed as 
Data Types (i.e., types that do not have a direct system represen¬ 
tation of their data structure) would be initialized by sending 
the message new to the appropriate class. Variables typed as 
basic Data Structures, such as Integer, Float, and Array, would be 
initialized at the primitive level. A possible set of initialization 
values for Data Structures might be: 

Integer 0 

Float 0 

Array 0 elements 

This arrangement would cover most cases, including the 
special initialization requirements that apply to some classes 


(e.g., OrderedCollection). Immutable Data Types (e.g., Character) 
that disallow creation of new instances present some difficul¬ 
ties, the main being that it is currently impossible for the sys¬ 
tem to determine whether a class is immutable. 

It would possible to initialize typed temporary variables in 
methods to nil, as is done currently, since the compiler would 
recognize that these variables remain untyped until an assign¬ 
ment takes place, at which point the typing could then be 
taken into account. This might be preferable to reduce initial¬ 
ization overhead. 

Runtime type checking is required to ensure that typed 
variables are assigned according to their declared type. This 
function would be performed by compiler-generated code that 
would perform the equivalent of an isKindOf: check prior to as¬ 
signment of an expression result. The system overhead of this 
check is minimal- In addition, typed arguments would be 
checked upon entry to a method. 

At compile time, Smalltalk changes a reference to a Dictio¬ 
nary variable into a reference to the Association containing the 
variable key and value to avoid a runtime dictionary lookup. 
However, dictionary variables may be updated through basic 
Dictionary messages at:put:, removeKey:, etc. This creates the po¬ 
tential for an integrity violation in Smalltalk (try removing an 
existing class variable with removeKey: then adding it again 
with at:put:). While it could be argued that one should not up¬ 
date dictionary variables in this manner, nevertheless it is an 
option open to the user. This situation is aggravated for typed 
Dictionary variables since there is no compiler-generated code 
to stand in the way of an incorrect assignment when using the 
basic Dictionary messages. Our present solution to this is to cre¬ 
ate a subclass of Association, call it ConstrainedAssociation, that 
would contain a new instance variable, constraint, and would 
inhibit incorrect assignment to its value. The class definition 
and methods for ConstrainedAssociation are shown in Listing 1. 
Note that our solution does not address the removeKey: in¬ 
tegrity problem that currently exists in Smalltalk. 

To manage static binding, we propose creation of the 
classes: 

BoundMethod 

Constraint (virtual class - no instances) 

B ehaviorConstraint 
iypeConstraint 

BoundMethod would be a tuple containing at least an “imple¬ 
menting” CompiledMethod, a “sending” CompiledMethod, and an 
instance of either BehaviorConstraint or TypeConstraint. Behav- 
ioiConstraint describes an instance of static binding, and Type- 
Constraint describes the less restrictive case of simple type 
checking. 

In the following example, let us assume the class hierarchy: 

Number 

Integer 

Smalllnteger 
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where the method max: is located in class Number. Then in the 
following: 

| (temp:Integer) (indexl.-Integer) indexZ | 
temp:■ indexl max; index2. 

the message max: would be bound to the method max: in class 
Number at compile time, and an instance of BoundMethod 
would be entered in the global Set, BoundMethods. This in¬ 
stance of BoundMethod would contain a BehavioiConstiaint The 
compiler rule used to determine whether a BehaviorConstiaint 
or a TypeConstraint is generated is fairly simple. If a method is 
redefined in any of the subclasses of the constraint class, the 
compiler will generate a TypeConstraint If such redefinition 
does not occur, the compiler will generate a BehaviorConstiaint. 

If the method max: was now defined in class Integer, the 
presence of a BehaviorConstiaint in BoundMethods would inform 
us that there was a “sending” method that required recompil- 


Llstlng 1. 

Association subdass: •ConstminedAssodatlon 

instanceVariableNames: 

'constraint' 
dassVaiiableNames:" 
poolDictionaries:" 

ConstrainedAssodation class methods 

key: aKey value: anObject constraint aClass 

'Answer an instance of class ConstrainedAssodation 
whose key is initialized to aKey, whose value is initialized 
to anObject, and whose constraint is initialized to aClass." 
aClass isBehavior 

iffalse: [ ''self error 'constraint must a Class ']. 

(anObject isKindOf: aClass) 

iffalse: [ ''self error ‘value must be kindOf, aClass name ]. 

A ( (self key: aKey) value: anObject) constraint: aClass 

ConstrainedAssodation methods 

constraint a Class 

‘Set the constraint of the receiver to be aClass. Answer the 
receiver.' 
aClass isM 
iffalse: [ 

(value isKindOf: aClass) 
iffalse: [ 

■'self error: ‘value must be kindOf *, aClass name ] ]. 
constraint :■ aClass! 

value: anObject 

'Set the value of the receiver to be anObject if anObject 
is an instance of constraint or one of its subclasses.' 
constraint isNil 
iffalse: [ 

(anObject isKindOf: constraint) 
iffalse: [ 

“self error ‘value must be kindOf', 
constraint name ] ]. 

value := anObject 


ing, and BoundMethods would be updated to reflect the new Be- 
haviorConstraint. 

If the method max: were now defined in class Smalllnteger, 
the compiler (using the rule mentioned above) would remove 
the BehaviorConstiaint and substitute a TypeConstraint In our 
system, BoundMethods must be loaded at system start-up since 
they will be invoked by direct function call. 

Dynamic binding would remain the primary and preferred 
way of associating messages with methods. Typing would be 
used in situations that caused performance degradation or as a 
data validation tool. Intuitively, the best use of typing applies 
in high-use areas where typed languages can typically produce 
very efficient code. Coincidentally, these areas correspond to 
functions in Smalltalk that undergo few changes since they are 
integral to the basic functioning of the system. Some example 
preliminary candidates for typing might be arrays, which are 
frequently used in the at: and at:put: messages, and array in¬ 
dices, which participate in integer operations. In some actual 
program samples we have studied, up to 40% of message rout¬ 
ing would be removed by static binding in these areas. 

Typing will probably be a compiler option that may be 
turned on or off by the programmer. Programs compiled for 
production would usually take the performance advantage of 
typing, while, in the development environment, typing might 
not be used to retain flexibility and fast compilation. ■ 

REFERENCES 

[1] Johnson, R. E-, J- O. Graver, and L- W. Zurawski. TS: an optimiz¬ 
ing compiler Smalltalk, OOPSLA ‘88 Conference Proceedings, San 
Diego, CA, October 1988, pp. 18-26. 

[2] Chambers, C-, and D- Ungar. Making pure object-oriented lan¬ 
guages practical, OOPSLA '91 Conference Proceedings, Phoenix, 
AZ, October 1991, pp. 1-15. 

[3] Palsberg, J-, and M. I. Schwartzbach. Object-oriented type infer¬ 
ence, OOPSLA '91 Conference Proceedings, Phoenix, AZ, October 
1991, pp. 146-161 


Glenn J. Reid is President and Founder of QSYS Systems Consultants, 
Inc ., a consulting and software development company whose main area 
of expertise ism the application of object-oriented technology. Architect 
of SmalltaIh/370, Mr. Reid is currently involved in the development and 
application of a complete project life cycle approach to developing object- 
oriented systems in a mainframe environment. He can be reached at 
(416) 343-6464. 


The Smalltalk Report 






p 


RODUCT REVIEW 


Reviewed by Jon Hylands 


Profile/V: a performance profiler for 
Smalltalk/V Windows 


P rofile/V, from First Class Software, is a code profiling tool 
that allows Smalltalk programmers to monitor the perfor¬ 
mance of their applications. It creates a weighted call tree 
of your code that basically shows the percentage of total run¬ 
ning time spent in each method- With this information, it is 
possible to find out where your code (or, just as important, sys¬ 
tem code) is causing a bottleneck. 

With a list price of $299.99, Profile/V is a tool that any 
Smalltalk programmer who is interested in writing high-per¬ 
formance code should include in their library. Although it 
needs some improvement in the user interface department, it 
is definitely money well spent. It is currently available for Dig- 
italk’s V Windows.V Mac, and V 286. Profile/V will be avail¬ 
able for V PM this month. 

HOW TO USE PROFILE/V 

Profile/V comes on one software diskette and includes a 50- 
page User's Guide/Tutorial. The manual's 29-page tutorial 
shows the optimization of a simple graphical application, 
which is included on the disk. The manual also includes sec¬ 
tions on installation, how to use the product, notes on how it 
is implemented, and a very interesting section on "Program¬ 
ming for Optimization." 

The only problem I had with the manual is the fact that 
the installation page is somewhere in the last half—when I 
look for the installation instructions, I expect them to be at 
the beginning. 

Profile/V uses an invisible window to capture timer events 
and takes a snapshot of the stack from the current user inter¬ 
face process when a timer event happens. It builds a profile 
object from these samples and then can open a browser on the 
profile. The browser is a subclass of the system-supplied 
method browser. The browser has three panes and it provides 
the user with the ability to go as deep as they want—right 
down to individual statements in a method. 

Other valuable features include the capability to gather 
method profiles for the same method and browse them as a 
new profile. This feature is ideal when profiling recursive 
methods. Another useful utility is the ability to take what is 
displayed in the browser and convert it into formatted text in 
a workspace for inclusion in documents (such as this one). 

You can also adjust the threshold value for the browser, which 
controls how many methods are shown when the browser is 


initially opened by hiding all methods that take less than the 
threshold percentage value to run. 

Perhaps one of the nicer things about Profile/V is its size, or 
lack thereof. The entire profiling system is only about 27K of 
source code, which makes it a product more likely to be un¬ 
derstandable and extendable. 

BUT MY CODE IS ALREADY FAST... 

Many programmers, myself included, will look at this tool ini¬ 
tially and say something to that effect. Unfortunately, in the 
case of Smalltalk, where you have a large library of reusable 
code written by someone else, having your code tun at light- 
speed doesn’t necessarily mean your application will be as fast 
as it can be. Programmers tend to make assumptions about the 
performance of other code, and these assumptions often turn 
out to be incorrect. This turned out to be the case for a graph¬ 
ics application I profiled. 

USING PROFILER TO OPTIMIZE A SAMPLE 
APPLICATION 

The application I ran my tests on was a simple magnifying 
glass, which first appeared in the Smalltalk column in the 
Journal of Object-Oriented Programming. 1 Since that time, the 
authors have made large number of changes to the code to 
simplify and streamline it. The magnifier simply simulates a 
magnifying glass on the screen and shows the magnification of 
a circular area. I limited the tests to a single method, which is 
the code that displays this circular magnified image, since it is 
the slowest part of the magnifier simulation. 

The first iteration of the profiler run on this method pro¬ 
duced the profile shown in Figure 1- It shows quite clearly 
(and quite surprisingly, also) that almost half the time spent 
in this method is in sending the pen message to bitmaps! 

The pen message is sent six times since we are performing 
five copyBitmap’s and one set of drawing commands to 
achieve the circular magnification effect. However, we can 
improve this since only two bitmaps are the receivers of the 
pen message. We can cache each bitmap’s pen in a tempo¬ 
rary variable at the beginning of the method, thus saving 
four pen messages. This works when performing copy- 
Bitmaps, but not when doing pen-based drawing, so the pen 
message must also be sent before the drawing section of the 
method takes place. 
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Figure 1. Initial profile. 


After making this modification, 1 again profiled the 
method, getting the results shown in Figure 2. As you can see, 
the pen message frequency had been reduced to 23%, which is 
half of the first run. 

And, as shown in Figure 3, you can see that the pen mes¬ 
sage has increased to 30% of the running time, but the bound- 
ingBox message has disappeared, and, as a result, the method 
runs faster. 

So you can probably see by now that this tool is a valuable 
one. 1 would never have guessed that the pen message is one to 
avoid, and, in a real-world application, things like that can 
mean the difference between acceptable and poor performance. 

PROBLEMS WITH PROFILED 

So far, the only problems I have had with Profile/V are small 
ones relating to the user interface. One is that the indent on 
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Figure 3. Final profile, with boundingBox message removed. 


the profile tree is hard to make out since each successive in¬ 
dent is only one space. I spoke with Kent Beck, the author, 
and he assured me that this had been changed in future ver¬ 
sions to make it more readable. 

The other problem is perhaps more important and it in¬ 
volves the way the children of a method are hidden and shown. 
In Profile/V, some of the direct children of a method may be 
visible, while others are not. This presents problems when try¬ 
ing to view your profile from a given depth since you often have 
to either do two double-clicks to get the desired results or use 
the Hide Children menu command- You can get around this by 
adjusting the threshold to be one (so it only takes one double¬ 
click), but personally I think it would be more useful to have a 
feature that allows the user to set a depth threshold rather than 
(or in addition to) a percentage threshold. 
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Figure 2. Profile with cached pens. 


FINAL WORD 

I found Profile/V to be an extremely useful piece of software 
and I will definitely use it in the future. In comparison, 1 have 
only briefly seen the profiler that Digitalk is shipping with 
Smalltalk/V PM 1.3. It is lacking in that it only produces 
fairly complex text reports and has no user interface to allow 
browsing of a profile. 

I recommend Profile/V as a solid addition to any serious 
Smalltalk developer's toolkit. ■ 
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OOK REVIEW 


Reviewed by Dan Lesage 


Object-Oriented Modeling and Design 

by J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen 
Prentice Hall, Englewood Cliffs, NJ, 1991 


I his is the book to recommend to your MIS/DP customers 
that are considering the use of OOP in their company but 
don’t know where to start down the path toward the Holy 
Grail. The investment in an OO language may be considered 
too risky for the average data processing manager, without 
knowing how OO can benefit his or her complete develop¬ 
ment cycle. In that regard, the DP manager will likely wish to 
understand the benefits of OO in terms of a formal methodol¬ 
ogy. Rumbaugh et ai. describe their object modeling tech¬ 
nique (OMT), which is a gentle mutation of existing struc¬ 
tured analysis/structured design (SA/SD) methodologies plus 
entity-relationship (ER) diagrams into an OO one. Should 
your DP customer already be using structured techniques in 
his or her shop, this book will help ease the transition toward 
OO. It should be no surprise that a large part of OMT follows 
Rumbaugh's own work in combining objects with relations at 
GE, as described in several of the OOPSLA Proceedings. 

The book consists of five major sections: motivation, mod¬ 
eling, methodology, implementation, and example systems. 
The motivation part covers the normal questions of why one 
would want to use OO techniques. The modeling section pre¬ 
sents the components of the OMT techniques that are based 
on three diagramming techniques. Two of them are (hope¬ 
fully) already being used by your MIS/DP customer: Harel 
state diagrams, which are used as the dynamic model, and data 
flow diagrams, which are used in the functional model. The 
object model, is an extension of entity-relationship diagram 
conventions incorporating class operations (methods) and in¬ 
heritance (in the Smalltalk sense). If you are familiar with 
these three basic techniques, the OMT methodology shows 
how information from the dynamic and functional models can 
gradually be pushed into the object model. OMT provides an 
evolutionary approach to ease people into the world of OO 
analysis and design, using existing modeling paradigms. 1 sup¬ 
pose that I should also mention that the pretty pictures are di¬ 
agramming conventions that you will already know if you are 
familiar with the above structured techniques. No three-di¬ 
mensional dodecahedrons, no dithered lines, no trisected 
equilateral triangles, etc. 

The strengths of the book and the methodology are many. 
The methodology draws on knowledge of familiar modeling 
techniques. It is soft and can be tailored in a number of ways 
for introduction into DP shops currently using structured 


techniques. The examples presented in the text are excellent 
since they have been drawn from real-world problems encoun¬ 
tered by the authors during the course of their research. 
Within the context of some examples, the authors describe 
how subsequent requirements information caused them to go 
back and adjust their models. They give the reader a view of 
the model over the life cycle of analysis and design rather 
than just presenting the “answer." There is very good coverage 
of some of the design issues involved when trying to incorpo¬ 
rate an OO design into systems containing components built 
with more traditional technologies, such as relational 
databases. The authors also attempt to provide practical ad¬ 
vice about implementing your OO design in non-OO pro¬ 
gramming languages. 

Another strength is that the book can easily be used for 
reference purposes. Each chapter contains a very thorough 
bibliography. The organization of the book is such that the 
reader can focus very quickly on the chapter that is relevant 
to his or her question. It contains a glossary. The book can be 
used as a supplemental educational text since each chapter is 
followed by exercises, with selected answers in the back. Fi¬ 
nally, the text is easy to read, which helps if the only time you 
have for technical books is after your spouse and kids have 
gone to bed! 

And, should your MIS/DP customer wish to compare OMT 
with other methodologies before going out to buy the latest, 
greatest CASE took or white boards, the authors have conve¬ 
niently included a chapter to make the decision easier. They 
compare OMT with SA/SD, Jackson structured development 
(JSD), and conventional ER modeling, describing under what 
circumstances they believe each model excek. 

There are few negative aspects about this book. The 
methodology may be confusing for people coming from an ob¬ 
ject-oriented background. The notion of having to map dy¬ 
namic and functional behavior into methods will be foreign 
since it is natural for them to think in terms of methods from 
the analysis stage. For OO types, the object model should be 
sufficient for the analysis. The chapter on system design is the 
weakest link in the life cycle chain, but it’s also the hardest in 
real life so, although it does not provide the system design 
cookbook, it does allude to many of the real-world deckions 
that are made during this stage of the model refinement. I was 

continued on page 18 ... 
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Excerpts from industry publications 


... Momenta built the [PenTop] machine around the object-ori¬ 
ented language Smalltalk. Everything in the PenTop's environ¬ 
ment is an object, so users can link anything in the machine— 
from internal toolbox functions to their own sketches, text, and 
presentations—to one another. The machine runs all popular 
DOS and Windows applications, and will support Microsoft's 
PenWindows when it becomes available ... 

Momenta Rewrites the Notebook Rules, Richard Doherty, 
Electronic Engineering Times, 10/7/91 

... In addition to the visual orientation, there are two other rea¬ 
sons I'm attracted to Serius' product. One is the level of ab¬ 
straction of the objects. Most object-oriented languages today 
are for professional programmers (e.g., C++ and Smalltalk) and 
that means the objects are at a relatively low level of abstrac¬ 
tion to provide sufficient control for speed and memory 
efficiency. Serius Programmer, on the other hand, has very ro¬ 
bust objects for an application generator ... The second reason 
I like the package is the relatively broad support for data types. 

A Serius Approach to Programming, Rich Bader, 
PC Letter, 9/16/91 

... Specialized OOP environments like Smalltalk tend to 
frighten programmers used to the procedure-oriented ap¬ 
proach of traditional languages...Although embedding OOP 
technology in existing languages like Pascal or C has really 
boosted OOP, the tendency for programmers using those tools 
is to keep on doing things the same way, with only a few 
changes. There's still a big learning curve, and, if you give a C 
programmer a C++ compiler, he'll probably just write C code, 
ft's hard to lose old habits ... 

... [Ron Fisher says] "Smalltalk's concepts are very different, 
but once you can deal with them conceptually, you can write 
much better programs. Smalltalk is a whole environment, not 


just a language. To me, C++ is a kit car, and Smalltalk is an 
Acura NSX. C++ wasn't thought out thoroughly as an object- 
oriented language. It exists because C exists. You can do a lot 
more low-level stuff in C that you can with Smalltalk. C lets you 
get at the iron much better, but if it wasn't for C, C++ wouldn't 
have much of a following"... 

Double Plus Good, Gordon McLachlan, HP Professional, 9/91 

... But in a world increasingly jammed with OOP proselytes, we 
still don't have an OOP graphics front end for these [graphics] 
libraries. I would like to see something that would give me 
ONE Object Oriented Design perspective with support for sev¬ 
eral graphics libraries ... 

Graphic Developer's Taste Test, William E. Gates, 
Midnight Engineering, 10/91 

... The more advanced pen-computing operating systems use 
object-oriented design for memory management. In contrast to 
desktop GUI applications, which may require multiple 
megabytes of memory, object-oriented applications typically 
require only about lOOKto 200K because the operating system 
conserves memory by eliminating redundant code ... 

Is the Pen Mightier?, Kathleen Melymuka, 12A-550 CIO, 9/15/91 

... Building a single, integrated model for the problem domain 
is something the securities industry has to do. We're face to 
face with the complexity of the solution right now. Other indus¬ 
tries won't be far behind. Take a close look at your own prob¬ 
lem domain; you may find that the celebrated paradigm shift is 
not a problem of changing the way people think but of dealing 
with the resulting solution ... 

The Complexity of the Solution, Bill Welch, 
Object Magazine, 9-10/91 


... continued from p. 17 

slightly thrown off since the style of the other analysis and de¬ 
sign chapters gave me much more concrete choices to make. 
And, since this is The Smalltalk Report, I can also say that the 
Smalltalk language is somewhat slighted as a potential choice 
for implementation language primarily because the authors re¬ 
fer to it as a weakly typed language. I believe that there exists 
confusion here between the use of strong typing and static typ¬ 
ing. As every Smalltalk programmer knows, Smalltalk is a 
strongly typed language. 

Overall, I highly recommend this book to anyone who is 
interested in learning more about OO analysis and design. It 
contains good, sound, practical knowledge drawn from real- 
world examples. The methodology is flexible, allowing its 
users to emphasize those modeling techniques that make sense 


in their shop, while deemphasizing those that are irrelevant. 
The book clearly gives a path that takes the modeler from 
known structured techniques and allows him to migrate this 
knowledge into the realm of OO analysis and design. In short, 
this book has something for everyone using or considering the 
use of OO technology. ■ 


Dan Lesage has been involved with object-oriented programming since 
1986 and Smalltalk since 1988. Currently, he is the Project Manager, 
Turnkey Systems at Object Technology International in Ottawa, 
Canada. His current interests include distributed computing, data 
communications, and object-oriented analysis/design. He can be 
reached at Object Technology International, (613) 228-3535, or 
dan@oti.on.ca. 
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Product Announcements are not reviews. They are abstracted from press releases provided by vendors, and no endorsement ls implied. Vendors 
interested in being included in t/iis feature should send press releases to our editorial offices, Product Announcements Dept. , 91 Second Ave., 

Ottawa, Ontario K1S 2H4, Canada. 


The Agorics Project announced the opening of an online Smalltalk 
Components and Consulting market on AMIX, the new electronic 
marketplace for information provided by Autodesk, a subsidiary of 
the American Information Exchange Corp. (AMIX). In this market, 
Smalltalk users will be able to buy and sell classes, methods, tools, 
applets, and any other Smalltalk-related information. Users will also 
be able to offer and request Smalltalk consulting services. Features 
include email, negotiation facilities, listings of sellers' resumes and 
references, listings of comments on components by previous buy¬ 
ers, and more. 

For more information, contact Howard Baetjer, The Agorics Project, 10364 
Bridgetown Place, Burke, VA 22015; phone and fax (703) 250-4760; email 
agorics0gmuvax.gmu.edu. 

InputForms is a program designed for the interactive development 
of input forms and all kinds of windows running under Windows 3.0 
and Smalltalk/V Windows. Features include the ability to interac¬ 
tively select child controls and define site, position, brush, fore¬ 
ground color, background color, font, etc. 

For more information, contact Viastimil Adamcvsky, 66 rue de Bourgogne, 
L-1272 Luxembourg; phone 352 420884. 


Empower Software has announced the availability of the Smalltalk 
Project Browser, a source code management tool for Smalltalk/V 
Windows and PM systems that adds a powerful layer of control to 
the Smalltalk environment. It is also useful as a development shell 
from which other Smalltalk development tools are launched. The 
Smalltalk Project Browser provides support for code porting and 
maintenance across Smalltalk platforms, management of class de¬ 
pendencies, system integration, automated code documentation, 
and code distribution and packaging. 

For more information, contact Empower Software, 9601 Wilshire Blvd., Sta¬ 
ll 44, Beverly Hills, CA 90210. 

Digitalk, Inc. has announced availability of a new release of its 
Smalltalk/V PM that gives software developers a jump start on de¬ 
veloping new applications that take advantage of the power of 
IBM's upcoming version 2.0 of OS/2. In addition to enhanced fea¬ 
tures and power, Digitalk's Smalltalk/V PM 1.3 release includes sup¬ 
port for IBM's Common User Access '91 (CUA) controls that are at 
the heart of IBM's new advanced 05/2 2.0 graphical user interface. 

For more information, contact Barbara Noparstak, Digitalk, Inc., 9841 Air¬ 
port Blvd., Los Angeles, CA 90045; (213) 645-1082; fax (213) 645-1306. 


Take Control of Your Applications with 


Bring your large, complex object-oriented applications under control 
with AM/ST, the Application Manager for Smalltalk/V. The AM/ST 
Application Browser helps both individuals and development teams to 
create, integrate, maintain, document, and manage Smalltalk/V 
application projects. 



Price List 


DOS V $150 

DOS V/286 $395 

Macintosh V/Mac $395 

OS/2 V/PM $475 

Site Licenses CALL 

New Productivity Tools 1 

Windows 3.0 

WWindows $475 

Change Browser* $195 

Source Control* 1 pm or window* 
first copy $1,595 

subsequent $595 



I SoftPert Systems Division 

! One Main Streel 

! Cambridge, MA 02142 

I (817)621 3870 or (617) 621 3671 Fax 
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• Applications Hierarchy 

Every class has an owner. 

Functional view across classes and related 
methods within classes. 

Applications port easily across platforms. 

■ A utomatic Documentation 

Revision history for each method. 

Analysis and design reports. 

Customizeable documentation templates. 

• Source Control 

Integrate work of several users. 

‘Save and browse multiple revisions easily. 
**Check-in, check-out, and lock source code. 
Customize code templates. 

Develop in a LAN environment. 

Deliver applications without AM/ST. 


Static Analysis Tools 

Application consistency reports. 

Graphical views of hierarchies. 

Cross-reference of variable and method usage. 
Up-to-date method index. 


■ Dynamic Analysis Tools 
Locate performance "hot spots." 

■ Determine test coverage. _ ' 
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WINDOWS AND OS/2: 
PROTOTYPE TO DELIVERY. 
NOWATI1C. 

In Windows and OS/2, you need prototypes. You have to get a sense 
for what an application is going to look like, and feel like, before you can write 
it. And you can’t afford to throw the prototype away when you're done. 

With Smalltalk/y you don’t, 

Start with the prototype. There’s no development system you can buy 
that lets you get a working model working faster than Smalltalk/Y 

Then, incrementally, grow the prototype into a finished applica¬ 
tion. Tty out new ideas. Get input from your users. Make more changes. 

Be creative. 


KEY FEATURES 

■ World's leading, award-winning object- 
oriented programming system 

I Complete prototype-to-delivery system 

■ Zero-cost runtime 

■ Simplified application delivery for 
creating standalone executable (.EXE) 
applications 

■ Code portability between Smalltaik/V 
Windows and Smalltalk/V PM 

I Wrappers for all Windows and OS/2 
controls 

■ Support for new CUA 91 controls for 
OS/2, including drag and drop, booktab, 
container; value set, slider and more 

I Transparent support for Dynamic Data 
Exchange (DDE) and Dynamic Link 
Library (DLL) rails 

■ Fully integrated programming environ¬ 
ment, including interactive debugger; 
source code browsers (all source code 
included), world’s most extensive Win¬ 
dows and OS/2 class libraries, tutorial 
(printed and on disk), extensive samples 

■ Extensive developer support, including 
technical support, training, electronic 
developer forums, free user newsletter 

■ Broad base of third-party support, 
including add-on Smalltalk/V products, 
consulting services, books, user groups 


Smalltalk/V gives you the freedom to experiment without risk. It’s 
made for trial. And error. You make changes, and test them, one at a time. 
Safely. You get immediate feedback when you make a change. And you can’t 
make changes that break the system. It’s that safe. 

And when you’re done, whether you’re writing applications for 
Windows or OS/2, you’ll have a standalone application that runs on both. 
Smalltalk/V code is portable between the Windows and the OS/2 versions. 
And the resulting application carries no runtime charges. All for just 
$499.95. 

So take a look at / V Y 

Smalltalk/V today. It’s time to make / 'W 

that prototyping time productive. 



This Small talk/V Windows application 
captured the PC Mfeek Shootout award—and 
it was completed in 6 hours. 


Smalltalk/V is a registered trademark of Digitalk, Inc. Other product names are trademarks or registered 
trademarks of their respective holders. 

Digitalk, Inc., 9841 Airport Blvd., Los Angeles, CA 90043 
(800) 922-8255; (213) 645-1082; Fax (213) 645-1306 


LOOK WHO'S TALKING 


HEWLETT-PACKARD 
HP has developed a network trouble¬ 
shooting tool called the Network Advisor. 
The Network Advisor offers a comprehen¬ 
sive set of tools including an expert system, 
statistics, and protocol decodes to speed 
problem isolation. The NA user interface is 
built on a windowing system which allows 
multiple applications to be executed 
simultaneously. 


NCR 

NCR has an integrated test program develop¬ 
ment environment for digital, analog and 
mixed mode printed circuit board tasting. 

MIDLAND BANK 

Midland Bank built a Windowed Technical 
Trading Environment for currency, futures 
and stock traders using Smalltalk V. 



Smalltalk/V PM applications are used to 
develop state-of-the-art CUA-compliant 
applications—and they’re portable to 
Smalltalk/V Windows. 





































